Technotes
On QuickTime Component Manager 3.0 & PowerPC Native Components
This Note contains information about the version of the Component Manager that shipped with QuickTime 1.6 and the changes necessary to support native PowerPC components. Contents CONTENTSAbout Component Manager 3.0The Component Manager in QuickTime 1.6.x and for the Power Macintosh (PowerPC) release has some new features. It has added the ability to automatically resolve conflicts between different versions of the same component. It will ensure that only the most recent version of a given component is actually registered. The Component Manager now supports Icon Suites for a component, so a component's icon no longer has to be just black and white. In addition, the Component Manager can support code written in the native format of the PowerPC.
The result returned for the Gestalt selector
For support of the Power Macintosh, the Component Manager has been extended to allow use of native PowerPC components. When the Component Manager loads a native component on the Power Macintosh, it uses the Code Fragment Manager and calls A component can support multiple platforms such as the 68K and PowerPC. Existing 68K code is always supported on the Power Macintosh through emulation. But you can also have native PowerPC code for your component to support better performance. The Component Manager will allow you to create a component that contains both code formats, so that you can support all platforms with a single component. The Component Manager also was extended in a way that allows for native PowerPC only components (without any 68K code support).
Extended ComponentResourceTheComponentResource data structure (the 'thng ' resource) has been extended. These extensions define additional information about the component. The complete data structure is shown below. The first portion is the same as the existing ComponentResource , with the new fields added at the end. The Component Manager determines if it is present by examining the size of the 'thng' resource.
struct ExtComponentResource { componentVersionThecomponentVersion field contains the version number of the component. This should be identical to the value returned by GetComponentVersion . For convenience, if this value is set to 0, the component is called to get the version. This is useful during development. The version number stored in the ComponentResourceExtension is used by the Component Manager to avoid having to load and call the component to retrieve the component's version during startup.
componentRegisterFlagsThecomponentRegisterFlags allow you to define additional register information. These flags are discussed below.
/* Component Resource Extension flags */The componentDoAutoVersion flag tells the Component Manager that you want your component registered only if there is no later version available. If there is an older version of the component installed, it will be unregistered. If an older version of the same component attempts to register after you, it will be immediately unregistered. Further, if a newer version of the same component registers after you, you will automatically be unregistered. Using the automatic version control feature of the Component Manager allows you to make sure that only the most recent version of your software is running on a given machine, regardless of how many versions may be installed.
The
kComponentUnregisterSelect = -7The componentAutoVersionIncludeFlags flag tells the Component Manager to use the component flags as criteria for its component search. If a component wants automatic version control, the Component Manager has to search for similar components. Normally, the Component Manager searches only for another component using the type, subType, and manufacturer fields of a ComponentDescription record. This flag tells the Component Manager to include the componentFlags in its search.
The
componentIconFamilyFinally, thecomponentIconFamily field allows you to provide the resource ID of a System 7 Icon Suite. If this field is 0, it indicates that there is no icon suite.
countThis is the number of elements contained in theComponentPlatformInfo array.
platformArrayThis is an array of elements that describe the code to be used for different platforms. If the platform is for 68K, then the information within this element is a copy from thecomponentFlags of the ComponentDescription and ResourceSpec of the original ComponentResource structure. This insures backwards compatibility with older Component Managers. If the component contains native code support for the PowerPC, then an element of the array will contain the information about its componentFlags , resource type, and resource ID.
The
gestalt68k = 1, /* Motorola MC68K architecture */ Component Manager version 3 routinesGetComponentIconSuiteGetComponentIconSuite returns an Icon Suite for the given component. This call works only under System 7 or later. If called on System 6, it returns an error. If the component doesn't have an Icon Suite but does have a Component Icon (as returned by GetComponentInfo ), GetComponentIconSuite creates an Icon Suite containing just the black-and-white Component Icon. In this way, you can use GetComponentIconSuite whether or not a component has an Icon Suite.
pascal OSErr GetComponentIconSuite(Component aComponent, Handle *iconSuite) RegisterComponentRegisterComponentResourceRegisterComponentResourceFileThe only change made to these routines was to modify the use of the global parameter. The upper byte now contains the platform ID to be used by the component being registered. This change is necessary because these calls do not have access to the ComponentResource which contains theComponentPlatformInfo . If the upper byte of the global parameter is zero, then the platform is assumed to be the platform68k.
Creating a PowerPC ComponentResourceThe basics step for running on a Power Macintosh with a native component are:
Creating the component code fragmentThe first step in creating a native PowerPC component is to port your code. For complete details on porting to PowerPC, see Inside Macintosh: PowerPC System Software. Especially important for the following discussion is an understanding of the Mixed Mode and Code Fragment Managers.
Like other code ported for PowerPC, anytime your code uses a callback function (
If, in response to a request code, your component dispatches to internal functions using Suppose your component currently responds to an open request as follows:
switch (params->what) MyOpen is an internal function callback, so you must create a RoutineDescriptor /UniversalProcPtr for it. MyOpen is declared as follows:
pascal ComponentResult MyOpen (Handle storage, ComponentInstance self);The first step is to create a ProcInfo value for this function:
enum {Next you must update your source to build a UniversalProcPtr and use it. You could use NewRoutineDescriptor for this purpose, but the disadvantage is that creates a heap object which your component must dispose of properly.
An alternate approach is to declare a global
#ifdef powercIf you want your code to be compilable for both 68K and PowerPC, using the Universal Interfaces, then to avoid a lot of conditional compilation, the following macros may be useful:
#ifdef powercThese macros, exactly analogous to CallComponentFunction and CallComponentFunctionWithStorage , generate the appropriate code when compiled for 68K and PowerPC. Note that the PowerPC macro expansion depends on the global RoutineDescriptor name being FuncNameRD, i.e., the name of the function with RD appended. The INSTANTIATE_ROUTINE_DESCRIPTOR macro can be used for that purpose:
#ifdef powercThis is identical to the declaration of MyOpenRD earlier, but simplifies the editing.
With all the conditional stuff out of the way, then the original code can simply be updated by replacing
switch (params->what)Repeat the above steps for all internal component dispatches you make.
Setting the main entry pointLastly, you must set up the entry point into your component correctly. Unlike a 68K code resource, a PowerPC code fragment (which your component will be) has a well defined entry point. The Component Manager, rather than just jumping to the start of the code resource, will call the main entry point, as defined when linking, instead.But the Component Manager is 68K code, which means your main entry point must be a RoutineDescriptor. You can set that up as follows:
pascal ComponentResult main (ComponentParameters *params,When you link the component, you must then specify MainRD as the entry point.
Packaging the PowerPC component into a resourcePowerPC development tools create your PowerPC code in a code fragment in the data fork of the file. Your component code must be a resource (the resource type and id are specified in the'thng' resource described below). You can use the MPW Rez "read" command to read from the data fork into a resource. For example:
read 'mycp' (130) mycomponent.pef;reads the code fragment from the file mycomponent.pef and creates the resource 'mycp' (130).
Providing an interface to the componentIf you wish your component to be called directly, you must also supply an interface so callers know how to call it. For standard functions, such as Open, Close, Version, etc., this is not a problem as the Component Manager supplies functions to do this for you. Nor is this a problem if you are writing QuickTime components, since QuickTime supplies standard interfaces and libraries for calling components.But one of the advantages of the Component Manager is it lets you define your own routines with their own parameter lists, and for these routines you must supply an interface. Typically, for 68K this involved providing callers an interface file with function prototypes for your calls and inline 68K assembly to actually make the call. Obviously, the inline 68K code is a problem for a native PowerPC caller, so you must provide glue to accomplish the same thing. The following discussion also applies to calling a 68K component from PowerPC code. The interface is the same, either way. To take the example for Inside Macintosh: More Macintosh Toolbox, page 6-30, you might have a call like:
pascal ComponentResult DrawerSetup (ComponentInstance myInstance, Rect *r) = ComponentCallNow is a macro that expands to inline 68K code that pushes additional parameters and then executes an A-trap to call the Component Manager.
The first thing when using the new Universal Headers is that the definition of
pascal ComponentResult DrawerSetup (ComponentInstance myInstance, Rect *r)The only difference in this declaration is that the `=' character is missing. This is necessary to allow the code to compile for both 68K and PowerPC.
For 68K code,
pascal ComponentResult DrawerSetup (ComponentInstance myInstance, Rect *r) ;You must now supply glue for DrawerSetup that does the same thing on PowerPC as the 68K inlines would do. The strategy here is to mimic what 68K code calling your component would do. Namely, push a bunch of parameters on the stack, then call the component. You do that by building a struct that looks like the parameters as they would appear on the 68K stack. Each call will require a different struct because each call can have different parameters.
Use the struct below (
The params field is a separate struct that exactly mirrors your parameters. This must be customized for your call. A separate struct is used here because it simplifies the sizeof calculation for the
Once you have the struct, initialize it as shown in the example, and call the component via
enum { Code for the Glue FunctionOnce you have the structure defined, create an instantiation of it, and initialize it. Finally, call the component usingCallUniversalProc as shown in the following example.
pascal ComponentResult DrawerSetup (ComponentInstance myInstance, Rect *r)Repeat the above steps for all the public functions for your component. To allow for future updating, the best way to make this glue available to your clients is to build the glue into a Code Fragment Manager shared library that is built into your component. Provide your client with an XCOFF file to link against. That way, if the glue changes, the client applications will not have to be relinked.
Creating the extended 'thng' ComponentResourceHere is how to create the'thng' ComponentResource for a component that supports both platform68k and platformPowerPC. This is the source for MPW Rez using the latest version of Types.r that supports the UseExtendedThingResource template. Before using the new Types.r you need to define the UseExtendedThingResource conditional with the value 1. A component defined with this resource will work for all previous versions of the Component Manager. By keeping the original portions of the ComponentResource setup for the platform68k information, it allows your component to work on all 68K Macintosh computers. Adding the new information about your code fragment for the Power Macintosh allows the Component Manager for that machine to use your native code.
resource 't
If you have a component that only supports the 68K Macintosh, then you do not need to use the extended ComponentResource structure. However, if you wish to utilize Icon Families and automatic version registration, then use the extended ComponentResource without the ComponentPlatformInfo and do not set the componentHasMultiplePlatforms flag of the componentRegisterFlags . You may also include the ComponentPlatformInfo if you wish to and just have a single element that describes your 68K component code.
If you have a "fat" component, with both 68K and PowerPC code, set the component flags as you would for the 68K only case and duplicate that information in the
If you have a component that only supports the PowerPC in native mode, then you must use the extended For the PowerPC case, you need to include a single ComponentPlatformInfo element that describes your PowerPC native component code for PowerPC implementations of your component to be registered. Set the component flags in the extended portion of the resource as you would normally. Component Manager Interfaces
Further Reference
Technotes Previous Technote | Contents | Next Technote |